1. Field of the Invention
The invention relates to mass data storage particularly with respect to system recoverability without utilizing audit trail mechanisms on the stored data. Specifically, the invention involves a method and apparatus whereby client applications operating in a digital computer system can store, retrieve and delete variable length packets of high volume, real-time data which cannot be archived because of volatility and cannot be audited because of volume. The invention is applicable to environments such as telephone voice messaging systems, manufacturing process control systems and laboratory data systems.
2. Description of the Prior Art
Requirements exist in the prior art for large volume data base systems that receive large numbers of variable duration data packets (referred to as Messages) in real-time and store the Messages to disk. Such systems require integrity and recoverability of the data in the event of a system interruption or I/O component failure. Once a client application of the system has been informed that a Message has been recorded, a system interruption or single I/O component failure must not result in loss of the message. A system of this type may involve the support of thousands of digital data channels where each channel is receiving or transmitting data in real-time at a rate of thousands of bytes per second. If all data channels are receiving data and writing the data to disk, the system may be required to provide a sustained throughput in excess of tens of millions of bytes per second.
Systems of this type must also retain Messages until they are deleted. Storage of hundreds of thousands of Messages, where each Message may be many thousand bytes in length, may be required Thus, such a system may be required to store tens of billions of bytes of data. When a client application requests that a Message be sent over a data channel, rapid response to the request is expected. For example, in a telephone messaging system, a request that a voice announcement be placed on a selected telephone line requires a real-time response in fractions of a second.
A prior art mechanization for effecting the above described requirements utilizes a data base with an audit mechanism that creates an audit trail of completed transactions. A structured data base is desirable because it provides rapid access to large volumes of data The audit trail provides protection from I/O component failures and system interruptions. The audit mechanism is implemented such that before each transaction is completed, records representing each altered data base record prior to and after an update are written to an audit file. In addition to the audit file, periodic dumps of the data base are effected where each record of the data base is saved. Thus, recovery can be effected from I/O component failures and system interruptions by utilizing the latest data base dump and the audit files.
For the environments described above which require recording high volume volatile data, the data base mechanization is not effective. In systems where the lifetime of typical Messages are less than 24 hours, nightly dumps of the data base do not provide any benefit. At the time of a failure, a large fraction of the Messages archived in the most recent dump will be obsolete. Additionally, in such real-time high data rate systems (in excess of 12 million bytes per second), implementing an auditing mechanism may not be practically realizable with present day peripheral devices. With an audit trail mechanism, the large amounts of data being processed must be sequentially written requiring writing to one peripheral in the I/O subsystem of the computer system. The state of the art in peripheral development is such that a cost effective peripheral device does not exist that is capable of absorbing data at the rate it is being processed so as to provide such an audit mechanism. Additionally, management of the audit media introduces prohibitively undesirably complex requirements.
Another approach in implementing a system of the type described above is a conventional ("flat") file on mirrored disk with a data base for an indexing or directory structure into the flat file. Such a flat file contains records utilized to store the Message data typically without an associated indexing structure. When records are written to a flat file, generally an audit trail is not created, thus obviating the above described disadvantages of audit mechanisms. However, data in a flat file is exposed to I/O component failures and system interruptions. In order to provide protection from isolated I/O component failures and system interruptions, two copies of the flat file are maintained with the copies of the file having no common I/O path or component with respect to each other. Routines which access the flat file consider both copies of the file as a single file When data is written to the file, both copies of the file are updated During reading operations of the flat file, data is read from a single file. If an error is detected while reading one copy of the file, the other copy can be utilized An I/O error will only be returned by the storage system if both copies of the flat file cannot be read. A file which is accessed in the manner described is referred to as residing on mirrored disk. Mirrored disk systems double the I/O demand during writing of records.
Utilization of mirrored disk can result in inconsistencies being introduced between the copies of the file. Such inconsistencies may, for example, be introduced in the following manner. A write operation is initiated to each copy of the file and updating of one file is completed. The system is interrupted prior to writing the information to the other copy of the file. When the system is reinitialized, an inconsistency will exist between the two copies of the file.
Normally, a flat file on mirrored disk does not provide an indexing structure to permit rapid access to the recorded data. In order to provide rapid access to the data, a combination of a data base and a flat file on mirrored disk could be utilized The data base provides the capability of efficiently accessing Messages utilizing a key. The data base would contain data comprising the record numbers in the flat file corresponding to each segment associated with a Message. An audited data base can be utilized because the records in the data base are small. The data base audit mechanism provides protection from I/O component failures.
Using a data base for an indexing or directory structure and a flat file on mirrored disk for data storage results in a number of desirable advantages. The data base provides rapid access to the segments associated with a Message. The mirrored flat file provides protection from I/O component failures and system interruptions without the disadvantages described above of an audit mechanism concentrated on a single peripheral device. It is appreciated that, although additional I/O operations are required when storing Messages, the I/O operations are distributed over the entire disk subsystem thereby permitting simultaneous writes. It is also appreciated, that the additional I/O operations to the flat file ar less than the I/O requirements for an audited data base as described above.
The processing method described, introduces an environment where the data base could be inconsistent with the flat file or where the flat file could be rendered inoperative. If the data base is rolled back (its logical state moved back in time) by applying images from the data base audit file, which images represent records prior to data base updates, or if the data base cannot be completely recovered from the audit file after failure or interruption, the flat file will be inconsistent with the data base. If this occurs, incorrect records in the flat file could be used or overwritten. Data base roll back is a commonly performed operation for the purpose of correcting logical errors such as those caused by a program that was run with incorrect input or that processed records in the data base incorrectly. Additionally, if the data base is irretrievably destroyed, the remaining flat file is rendered useless. Furthermore, if write operations to the flat file are interrupted by a system failure, the two copies of the flat file will be rendered permanently inconsistent with respect to each other. Also, a Message will become "orphaned" (permanently allocated but unknown to any client) if the Message is received and stored but the system is interrupted before a client application has recorded the existence of the Message in the data base of that client. The system will be unable to store additional data if enough Messages become orphaned.